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Abstract— Java Card new technology enables smart cards and other devices with very less memory Jj^\p 
small applications, called applets, which employjava technology with a secure and interoperable ex^fcion 
platform that can store and update multiple applications on a single device. A smart ca^j"i<mtime 
environment must provide the transaction support for the reliable update of data, especj<5jfc/<efi multi- 
application cards like the Java Card. The JAVA CARD transaction mechanism allows prs/elb/g sensitive 
operations on smart cards against problems due to card tears or power losses^fetements within a 
transaction are viewed as a single atomic operation so that either they are all perfornraLo* none of them is. 
We consider security problems that can be caused by a card tear. One of the jmaWerious problems of 
Smart Card System such as Java Card is about an amount of insufficient mapsS^Java Card technology 
provides a secure, vendor-independent, ubiquitous Java platform for smar^/^rds and other memory 
constrained devices. It opens the smart card marketplace to third^psrtXapplication development and 
enables programmers to develop smart applications for a wide variet^af^itffors 1 products. 



rie^qfV 
[1, Introduction Qy*^ 



Normally, there are 256 byte code instructions in StandarqUWa* However, Java Card is implemented as a 
subset of the Standard Java for a limitation of a typic^jfcsource-constrained device. We discover that 
instructions of 186 to 253 are neither specified nor resere* These free instructions can be transformed into 
new instructions for improving the performance ofaiVefnd space. 

Smart card support is a component of the IT^frastructure in a growing number of sectors [5]: banking, 
mobile and non-mobile communications, H^a\cess, government, multimedia, etc. Most of the applications 
require a high-degree of reliability. Ja\^TVahd [6] is one of the leading technologies in this sector as it 
provides significant features: mi&»|^"Spplications, portability, and compatibility with a popular 
programming language technology (JaSaY 

The B method [7] is a ooo^rarraidate for such process. Based on the experience gathered from the 
development of formal spXMation languages such asVDM and Z, B is one of the foremost formal methods 
with a strong industriaksV(i|ort. Smart cards provide the secured access to stored data. Data on the smart 
card is usually not au&05\e for an external 

Application urrtfl^nas authenticated itself to the card sufficiently. If the communication only consists of 
read accessevNje card can deliver the requested data without compromising the security and integrity of 
the storet^fti. If the external application creates or updates data on the card, care must be taken that the 
inteari^tfthe data is preserved throughout the communication. Either all updates take place during the 
OTnrn|rTrcation or the data on the card is reverted to its initial state in case of an interrupted execution. [2] 

Current applications typically flag their data on the card to be inconsistent with the first write access during 
a series of updates. After all updates, the terminal application finally records its data on the card to be 
consistent again. If a terminal application is faced up with a card in an inconsistent state, its state may be 
reset by the terminal application itself, but more often must be fulfilled under special authority within a 
trusted environment. The dependency of the smart card consistency on external applications can be 
accepted as long as the smart card is only used for a few critical applications where any irregularity must be 
recorded and checked at a central site. Otherwise, a smart card should not only be able to verify the access 
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rights of an external application, but should also provide a tighter control over the consistency of the 
internally stored data. Especially, on multi-application cards where each application on the card has access 
to its own data, applications must also be able to control the integrity of their data. First, the system is 
required to ensure that all updates of an application are performed atomically; second, it must perform 
crash recovery to provide stability: the system must recover its state and the state of the applications to a 
consistent state if a transactional computation fails. A simple transaction model on the card may only 
support user level transactions in the traditional sense. Transactions can be assumed to begin and end 
within the communication with a terminal application, are thus short lived and need not be split in 
multiple sub transactions even if multiple applications cooperate together. However, theimplemen|ateJ^f 
a transaction mechanism is hindered by the extremely limited resources on a smart card. WitOyM 
capacities around 1Kbyte and writable EEPROM capacities around 16 Kbyte the action implawTerjtation 
must be carefully chosen. In case of the Java Card, the underlying standard Java environment^^ first be 
extended to offer integrated transactional computations. The familiar programming comrei^fice of Java 
should be retained while the necessary resource demands must be kept as minimal asp^silHe. [2] 

The JAVA CARD programming language [4] is a JAVA dialect tailored to the de\ 
for smart cards, called applets. Its core language is a strict subset of the JAVA oj 
a set of restrictions due to the resource-constrained smart card environment. 



II. Java Card Introduction^^) 




?nt of applications 
^riented language with 



Sun Microsystems publish the Java Card Platform Specification and^s^ava Card Development Kit, which 
includes a reference implementation based on the specification^^viding the basis for cross-platform and 
cross-vendor applet interoperability, version 2.2.2 of the specrficaji<5n includes three documents: 

The Java Card Virtual Machine Specification definB^Utrre features, services, and behavior that an 
implementation of the Java Card technology must suififcsfct. 

The Java Card Runtime Environment Speuficatron defines the necessary behavior of the runtime 
environment (RE) in any implementation qfa^^iva Card technology. 

API for the Java Card Platform (*r^\|jfents the Java Card Runtime Environment Specification, and 
describes the application programnHflS*iterface of thejava Card technology. 

The Java Card DevelopmeiU^yrs a suite of tools for designing implementations of the Java Card 

— 3F— 



Table I 

Java Card Component size in Kilobytes 



Virtual machine 


4.0 


Memory management subsystem (including 
transaction support) 


4.0 


Garbage collector for RAM and EEPROM 


15 


DES implementation (no hardware) 


14 


RSA/DSA implementation (PK coprocessor) 


2.4 


On-card RSA/DSA private- key generation 


0.6 
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PKhash algorithm (SHAD 



T =lprotocol 



T =0 protocol 



T =CL (contactless) protocol 



Java Card system classes (no crypto) 



Java Card crypto classes (IBM proposal) 0.7 



Java Card crypto classes (JC2j) 



OP implementation (mixed native/Java code) 8.0 



Full-fledged Security Domain support 



Applets required to be in ROM for VOID 
Compliance 



A. Applet Execution 



0 



Thejava Card environment shares the basic architecture with thl^lndard Java environment. H owever, due 
to the limited resources on current smart cards thejava CaraL^acrifices a number of Java features. 

The runtime environment initiates the applet inst^jw^n by calling the installQ method of its class 
instantiating an applet object and registering it ay^rontime environment. An external application can 
initiate a session with the installed applet by SN^nng it first at the runtime environment. The select 
command will be forwarded by the runtimej^he applet's select () method, each following command will 
be forwarded to its process () method. The<C|H.et processes each command and returns from its invocation 
with a response for the terminal appNqgflyK Thus the invocation of the applet is event driven until the 
rr or selects a different applet where the current applet is notified 



remote application finishes the card! 
by the invocation of its deselect^] me" 



The applet instance 
storage on a card, 
important differ 
more than thij 
chips by inil 
written *" 
sudden 



B. Memory Management 

dated persistent objects of an application are placed in the non-volatile 
EEPROM, provides similar read and write access as RAM does, but with the 
lat the number of physical writes is limited and writes to EPROM cells are typically 
slower than writes to RAM . Performance of writes can be increased on many current 
block writes instead of multiple single EEPROM writes where individual bytes are 
ilfel to EEPROM. Neither single byte nor block writes are guaranteed to succeed in case of 



r loss, the write operation can suddenly fail after an arbitrary number of bits have already been 
fius the runtime environment can only rely on the outcome of a single flag write as the basic 
buVli/g block for transactions. Both RAM and EEPROM size is extremely limited on current smart card 
hardware, ranging typically up to 1Kbyte for RAM and up to K Kbyte EEPROM for current Java Cards. 

In contrast to EEPROM, RAM loses its value in case of a power loss. For repeated, performance and security 
sensitive computations, RAM must be usable by Java Card applications. For instance execution state, 
operand stack and local variables must be placed in RAM by the virtual machine. Our model extends the 
Java Card specification by allowing any type of object to be placed both in EEPROM as well as in RAM. The 
system is described in detail in and especially allows the easy deployment of a RAM garbage collector. Data 
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located in RAM , i.e. execution state and transient objects, is not considered to be part of the persistent state 
and its manipulations are not recorded during the transaction due to a number of reasons, among which 
are performance penalty and security implications. Thus, only changes to the applet objects in EEPROM 
must be covered by the transactional mechanism. [2] 

1 1 1 .Java Card Specific Features 

The Java Card runtime and virtual machine also support features that are specific to the Java Card platform: 
Persistence: With Java Card, objects are by default stored in persistent memory (RAM is very scay 
smart cards, and it is only used for temporary or security-sensitive objects). The runtime environi 
well as the byte code has therefore been adapted to manage persistent objects. 

Atomicity: As smart cards are externally powered and rely on persistent memory, persiste*|^fuates must 
be atomic. The individual write operations performed by individual byte code instructions a\j API methods 
are therefore guaranteed atomic, and theJavaCard Runtime includes a limited trans^fiNa. mechanism. 



Applet Isolation: The Java Card firewall is a mechanism that isolates the di1 
card from each other. It also includes a sharing mechanism that allows am 



object available to other applets. The JAVA CARD programming langi 
features that come from the characteristics of the smart card embf 
induced by the nature of the underlying hardware; others are giv< 
security needs. 



In JAVA CARD, the memory is organized in a completely dil 
between persistent objects (stored in EEPROM) and trc 
values of persistent objects are available during the wl 
objects and their fields. However, transient data at' 
terminal because they do not survive in the ab: ^ 





applets present on a 
to explicitly make an 



:ojjTSins several highly specific 
'ironment. Some of them are 
for the programmer to handle 



ejjTWay than in JAVA. A distinction is made 
(or volatile) objects (stored in RAM). The 
Ird life cycle; it is typically the case for applet 
tred after each session between the card and a 
if power. Generally, in JAVA CARD programs some 



large arrays are allocated in transient memoryJjji order to compute auxiliary calculations faster. 



Smart cards can be tear out of the termiasj^aaer at any moment during a session. As a result all transient 
objects are cleared and persistent oae^V^ft in the state they were at the precise instant of the power loss. 
A major issue for the security of arH^bedded application is to preserve data integrity and to maintain a 
coherent memory state in case ^ ar occurs. 

Another topical problem\s(^fensure data consistency in case a card tear occurs during a sequence of 
several updates to persidfe\ memory. To that aim the JAVA CARD API provides a so-called transaction 
mechanism — as tho^tclatabase systems — that makes a set of statements as if it was a single atomic 
operation. All the i/fttaws are effectively done or none of them is. 

The class ja^GNTramework.JCSystem contains the methods for using the transactions. Concretely, a 
transactiohfcrarrs with a call to the method beginTransactionQ and the changes made from that point only 
becoma^lsttive after commitTransaction() is called. A transaction can be aborted either by the system (i.e. 
th^^p&AARD Run time Environment) if a card tear — or more generally any sudden power loss — or a 
rfKjmcJy buffer overflow occurs, or by the programmer thanks to the method abortTransactionQ. In such a 
case^ersi stent objects are reset to their values in the state just before the transaction. Transient memory is 
not at all affected by transactions, thus any assignment to a volatile variable is done unconditionally.^] 

In JAVA CARD, the memory is organized in a completely different way than in JAVA. A distinction is made 
between persistent objects (stored in EEPROM) and transient (or volatile) objects (stored in RAM). The 
values of persistent objects are available during the whole card life cycle; it is typically the case for applet 
objects and their fields. However, transient data are cleared after each session between the card and a 
terminal because they do not survive in the absence of power. Generally, in JAVA CARD programs some 
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large arrays are allocated in transient memory in order to compute auxiliary calculations faster. 

Smart cards can be tearing out of the terminal reader at any moment during a session. As a result all 
transient objects are cleared and persistent ones are left in the state they were at the precise instant of the 
power loss. A major issue for the security of an embedded application is to preserve data integrity and to 
maintain a coherent memory state in case a card tear occurs. 

Another topical problem is to ensure data consistency in case a card tear occurs during a sequence of 
several updates to persistent memory. To that aim the JAVA CARD API provides a so-called transj 
mechanism — as those of database systems — that makes a set of statements as if it was a single^ 
operation. All the updates are effectively done or none of them is. 

The class javacard.framework.JCSystem contains the methods for using the transactione.^Jhcretely, a 
transaction starts with a call to the method begin Transaction () and the changes madeCEromViat point only 
become effective after commit Transaction () is called. A transaction can be abortej^^jer by the system 
(i.e. theJAVA CARD Run time Environment) if a card tear — or more generally am^j/fen power loss — or 
a memory buffer overflow occurs, or by the programmer thanks to the method abVOTransaction (). In such 
a case, persistent objects are reset to their values in the state just before thetr^^ction. Transient memory 
is not at all affected by transactions, thus any assignment to a volatile vatiaW^ i^tfone unconditionally. [3] 



IV. Smart Cards and Java 



itilevatiaW^ i^ 



An increasing number of IT applications require that users provi^yata via a portable device. Moreover, for 
security reasons, it is desirable that such devices include at teasfslmple processing capabilities. The smart 
card technology answers these needs and gains acceptanJfesVd popularity. Unique amongst the different 
smart card operating platforms, Java Card provides ven^LAimer-operability and has now reached a de facto 
standard status in this industry [1]. 

The Java Card platform provides a subset of theJavai)rogramming language. It allows memory-constrained 
devices, like smart cards, to run application a secure and interoperable way. Security is obtained 
through Java elements, like its secure a*q^ic>n environment, which controls, for instance, the level of 
access to all methods and attribute*; ^il^Jle applet separation by a resource named applet firewall. Inter- 
operability is the characteristic J±aHjjSws the execution of a Java Card application in any smart card that 
follows the Java Card specifications, independently of hardware and software manufacturers, without or 
with few code modifications.^i^^^ 

The use of this technolowYnngs many improvements for the developer of smart card applications. The 
ease of programminr/TKjava, that abstracts the low level details of the smart card system; and Java 
development tqol^lliwe IDEs, simulators and emulators) allow a rapid application build, test and 
installation cyd^rairecing the time and the cost of software production. Moreover, other benefits are the 
possibility of^wuNiple applications to coexist in a same card and the ample compatibility with smart card 
internatiorifeXfaridards, like ISO 7816. 

Tbed^ard platform provides a subset of the Java programming language. It allows memory-constrained 
dawcm like smart cards, to run applications in a secure and interoperable way. Security is obtained 
through Java elements, like its secure execution environment, which controls, for instance, the level of 
access to all methods and attributes; and the applet separation by a resource named applet firewall. Inter- 
operability is the characteristic that allows the execution of a Java Card application in any smart card that 
follows the Java Card specifications, independently of hardware and software manufacturers, without or 
with few code modifications. 

The use of this technology brings many improvements for the developer of smart card applications. The 
ease of programming in Java, that abstracts the low level details of the smart card system; and Java 
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development tools (like IDEs, simulators and emulators) allow a rapid application build, test and 
installation cycle, reducing the time and the cost of software production. Moreover, other benefits are the 
possibility of multiple applications to coexist in a same card and the ample compatibility with smart card 
international standards, like ISO 7816. 

A. Smart Card system and communication model a smart card system is composed of hardware and 
software components. These components are: Support software, software for communication with the card 
acceptance device (CAD), the CAD itself and the smart cards and their applications. 

User-CAD communication software (host application) this software is responsible for the commurtA^jon 
between an external application, called "host application", and the code running inside the cagkll^sends 
commands for the smart card application and receives the responses to these commands. ThlM^are can 
be included in a desktop computer, in a cell phone or in a security subsystem. \^ 

Card Acceptance Device (CAD): A CAD is the device located between the host appiSspf! and the smart 
card. It supplies power to the card and is the means of communication betweerUH^bst application and 
the application inside the card. A CAD can be connected to a desktop or a termV^j such as an electronic 
payment terminal. f/V 

Smart Cards and their applications: Applications are stored in the car^i^cjry. This can be done when the 
card is being manufactured, installing applications in its ROM merr£^3*Tater, installing the applications 
in the card's non-volatile and writable EEPROM .memory. Thej^^pM memory can also be written by 
applications to store their data. Smart cards also have a (fastd^^AM memory to store temporary data. 
Languages like C, the assembly language of the card an\ J|va Card can be used to develop these 
applications. Today, Java Card is supported in more thaa^^ [8] of the cards and is considered the best 
choice when productivity and security are the main requirements. 

Support software: This kind of software provides s^Aes to a smart card application. For instance, we could 
have an application that allows the applet to a^esscTcredit card operator service in asecureway. 

B. The Java Card JfevWote Method Invocation Framework 

The Java Card RM I assumes that trre^^t application needs to use a service provided by an applet on the 
card as an application programing interface (API). This service is specified as a Java interface that extends 
directly the predefined Java Rs^pjt interface. The methods of the corresponding implementation class are 
invoked from a different JtftC^machine (in this case, the host-side virtual machine). This implementation 
class needs to be develofegin the Java Card dialect. This class shall inherit from the CardRemoteObject 
class provided by thefjaw^Card RM I framework that provides methods to enable and disable the remote 
access to object^ T/fetWl also provides the class RM I Service that translates method invocations to APDU - 
level communi^i^/ Java Card imposes restrictions due to the very nature of the platform it runs on: 
there is a resetted set of basic data types, no threads, no guarantee that there is a garbage collector either. 
Also, in or^^a avoid loss of data consistency on the card, the Java Card framework provides transaction 
faciliti98j«!well as specific mechanisms to distinguish persistent data (need to be maintained when the 
ppflSoU/rned off) from transient data (may be erased when the card is reset). 

In the Java Card environment, applications are called applets, and are classes inheriting from the java 
card.framework.Applet class. An applet must provide an implementation for the methods install and 
process. The install method creates the applet by invoking its constructor method and registers it in the 
Java Card Runtime Environment (JCRE), by invoking the register method. The process method receives the 
APDU messages of the host application, does the initial processing of these messages, and invokes a 
method, passing to it the APDU object as a parameter. In Figure 3, we present on an example how the 
implementation of Remote object can be integrated into an applet and associated with a RM I Service object 
responsible for the communication with the host-side. 
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Finally, a reference to the remote object needs to be created on the host-side. The Open Card framework 
provides functions to get such reference. Once bound to a local object, the RMI is transparent to the 
programmer. 

C . E I em ents of J ava C ard Program m i n g 

Programming for a smart card requires special care against two possible problems: 



Available memory Smart card usually has a very limited amount of memory; in addition, the rui 
environment does not necessarily have a garbage collector. 



The programmer needsto apply specific memory allocation strategies. For instance, a methoi 



:hocLy^b 



avoid, 



at all cost, allocation of objects, as there is no available garbage collection mechanisan|^Jius, object 
allocation is usually restricted to the constructor. Also Java Card provides a special e£epr^n mechanism, 
where the cause of an exception is a short value instead of a string as in Java. This rr^dWifem is optimized 
to avoid multiplicative the number of exception objects in the card memory. /»^^ 



Data coherency the smart card may be physically removed from the card 
causing a power failure and interrupting the execution of the virtual mi 
inconsistent states, Java Card provides a transaction mechanism that 
a cost). In addition, objects may be specified as being persistent (mi' 
off) or transient (are reinitialized when power is turned off). 

V. Conclusion 




ice device at any time, 
'avoid that objects get into 



tees atomicity of execution (at 
idr value when power is turned 



The main contribution of this work is to provide \ 
components for smart card aware applications, ba 
integration of transaction support in the Java Caj " 
the Java Card 2.1 specification which only^reqTT 
transactional computations. 



only^eq 



: for a rigorous development of Java Card 
the B method. This paper presents the effective 
.reports the basic transaction semantics required by 
■es the minimum functionality needed for simple 
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